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1. INTRODUCTION 


The purpose of this document is to explain, prior to contractual delivery of 
the DORCA computer program, functions and capabilities of the program. 

This document is not intended to be a substitute for the User's Manual or the 
Programmer's Manual which are to be delivered with the DORCA computer 
program but is intended to inform (in a general sense) of the existence and 
purpose of the program so that a preliminary evaluation of program appli- 
cability to areas of responsibility can be made by potential users. 

The final version of the computer program, with attendent documentation, 
will be officially delivered to NASA by 15 September 1972. 

Several preliminary or interim versions of the DORCA program are in exis- 
tence and are contained in both The Aerospace Corporation and NASA-owned/ 
leased equipment. These interim versions of the program have, in fact, been 
used in conducting analyses for NASA, in parallel with the primary effort of 
completing development of the program. Included in the documentation to be 
delivered with the finalized computer program is a data bank, consisting of 
input card decks generated in conjunction with analyses that were performed. 

The computer program was designed for implementation on the Univac 1108 
computer, although development and debugging of the program was accom- 
plished on CDC 6000 and 7000 series machines. An interim version of the 
program was operative on the Bellcomm Univac 1108 in Washington prior to 
the termination of the Bellcomm contract. A minimal follow-on effort is 
scheduled for FY-73 to keep the DORCA program code and accompanying 
data banks up-to-date. 
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2. BACKGROUND 


The DORCA computer program was developed as a tool to be used by NASA 
Headquarters in conjunction with a long range planning function. As such, 
the computer program was designed for assessing an integrated space pro- 
gram as a whole, rather than for performing "mission analyses" of indi- 
vidual missions comprising the space program. Since little is known about 
detailed schedules of the proposed payloads or about the actual flight tra- 
jectory and vehicle performance characteristics associated with payload 
deployment, the program operates on "nominal" values of these parameters 
so that an analysis can be accomplished; without using nominal values, an 
analysis could not be conducted. Schedule for the program is considered in 
terms of fiscal year blocks; vehicle performance is computed using the ideal 
velocity equation and assuming a four-burn flight profile; mission AVs are 
based solely on the final orbital placement with a user option to increase the 
AV if significant addition to AV is required for rendezvous or other maneu- 
vering sequences. In this manner, programs can be analyzed very adequately 
for program planning purposes without a great deal of detailed knowledge of 
individual missions. Basically, in the computer program, payloads to be 
delivered in a given year and vehicles assigned to deliver the payloads are 
summarized. In this way, elements of the integrated space plan are integrated 
into one composite structure. The outcome of these summarizations and 
assignments, over a period of time, are vehicle flight rates, vehicle fleet 
and acquisition requirements, and cost estimates for conduct of a total space 
program. The procedures and computations involved in summarization and 
assignment operations are for the most part simple ones; however, the num- 
ber of applications of the procedures and computations required and the 
amount of data involved become so extensive that the time required to do the 
job manually is prohibitive. This is especially true if successive iterations 



involving perturbations to a baseline space program are required as in the 
case of an optimization analysis. For these reasons, a decision was made 
early in the study to mechanize the procedures and computations so that rea- 
sonable turnaround times could be obtained for the analyses desired. 

The basic philosophy behind the design of the computer program was the 
belief that a space program could, in simplest terms, be described as an 
exercise in cargo transport. From a purely logistics point of view, the 
objectives of a mission become important only to the extent that require- 
ments are created for the development, acquisition and transport of per- 
sonnel, equipment, and services. A mission can, therefore, be fully 
described by specifying when, where, and how cargo is to be transported. 

In this respect, the mission assumes the characteristics of a commercial 
trucking /moving operation. In order to specify when, where, and how the 
cargo is to be transported, much data have to be assimilated. A major por- 
tion of the DORCA program code is dedicated to process and determine "how" 
cargo is to be transported. 
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3. PROGRAM INPUT /OUTPUT 


3. 1 PROGRAM INPUTS 

Input data required by the DORCA program are provided on punchcards (or 
card image) and exist basically in two parts as noted in Fig. 1. One part 
contains all of the basic data describing the physical and/or functional char- 
acteristics of the elements that comprise a given space program. Included 
arc characteristics of the vehicles to be considered, cargo items to be trans- 
ported, containers, payloads mission trajectories, and cost/cost distribu- 
tion. These basic data elements contain all the information required in the 
DORCA II program for executing the procedures and computations necessary 
to evaluate the space missions /programs outlined in the mission data. Mis- 
sion data are the other part of the input data. Mission data delineate, when 
each mission is to be conducted (performed), final destination for each mis- 
sion, transport vehicle criteria for each mission, and name and number of 
cargoes to be shipped in conjunction with each mission. 

3. 2 PROGRAM OUTPUTS 

Program outputs consist of tabulated listings reporting on vehicle traffic, fleet 
requirements and acquisition schedules, individual mission utilization (flights) 
of vehicles, detailed flight vehicle cargo manifest, and program costs broken 
into three categories: vehicle, payload /facility, and operations (see Fig. 1). 

A vehicle traffic report gives the number of flights by individual vehicle and 
by fiscal year for the entire space program. This report also contains com- 
position of the fleet by fiscal year and acquisition schedule of the fleet. 

A vehicle utilization report gives distribution of flights by mission, vehicle 
name, and fiscal year. This report is the basis from which operations costs 
are computed for all of the missions comprising the space program. 
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Fig. 1. DORCA Input Requirements and Output Report 




Vehicle and payload RDT&E costs are allocated on the basis of first-use date. 
Recurring production costs are distributed throughout the program lifetime 
at the time new or refurbished elements are acquired. 

Using DORCA data, a flight vehicle cargo manifest report is usually printed 
only if the user desires detailed information on how individual vehicles were 
loaded. The report is grouped on a leg/vehicle/year basis and includes 
every combination cargo /vehicle configuration. The report also indicates a 
flight number for each vehicle flight within a given year. The number, how- 
ever, refers to the order in which the vehicles were loaded and not the order 
in which they are to be flown. The DORCA program is not expected to pro- 
duce, necessarily, satisfactory flight schedules for the shipment of cargo. 
The cargo manifest is assembled to display how the cargo items are grouped 
for shipment and it is assumed that scheduling problems can be solved in the 
future when constraints to be applied become known. 
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4. MAJOR PROGRAM FEATURES 


The DORCA program consists of a large number of subroutines. In each of 
these subroutines a specific function is performed within the program. Some 
subroutines deal with procedures and computations relating directly to the 
space program under analysis while others deal with the more subtle aspects 
of internal communications; e. g. , identification, storage, retrieval and rout- 
ing of all data involved in the analysis. Despite the relatively large number 
of subroutines involved, the DORCA program can be functionally defined with 
the four major features shown in Table 1. 

The first of these features, the CARGO LOADING, encompasses procedure 
and computations associated with the assignment of cargo /vehicle combina- 
tions. Cargo item numbers, weights, and lengths are accumulated as the 
loading operation progresses and are compared to vehicle capabilities and 
other loading restrictions to assure that vehicles are not overloaded nor 
applicable restrictions violated. 

The second feature, the PROPELLANT COMPUTATION, permits summing 
of propellant requirements for vehicles operating on all missions legs, except 
those legs having the ground as one terminii. This summing can be done in 
one of two ways at the option of the user. With the first method, fully loaded 
vehicle propellant tanks are assumed; in the second method the propellant 
required is computed based on the payload weight being transported by the 
vehicle. In both cases, the propellant, in appropriate tankage, is automati- 
cally added to the cargo list to be transported on the predecessor mission 
leg. 

The third feature, the VEHICLE TRAFFIC /FLEET COMPUTATION, is used 
to assign to individual vehicles, all flights generated by the cargo loading 
process. Within this feature, all of the bookkeeping is performed related 
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to flight time and flight history of individual vehicles. The number of flights 
of a given vehicle in a given year and the total number of vehicles required 
in that year, are determined. In addition, vehicles are retired at their 
assigned end-of-life and new vehicles are acquired as dictated by yearly 
flight requirements. 

The fourth feature, the COST COMPUTATION, includes the distribution of 
RDT&tE and recurring procurement costs at that time when logistics elements 
are activated and procurements are made. This distribution is in accordance 
with dollar values and with distribution functions supplied in the input to 
DORCA. Operating costs determined on a yearly basis are based on the 
number of vehicle flights and the direct operating costs per flight. 
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5. FUNCTION OF MAJOR FEATURES 


5. 1 TOTAL PROGRAM FUNCTION 

The real heart of the DORCA program is the cargo loading feature in which 
cargo items are assigned to vehicles on each of the legs comprising the 
mission trajectory; assignment is made independently and sequentially. 

Only the cargo delivery requirements for the outermost leg of the mission 
is specified for the DORCA program. With DORCA, cargo requiring con- 
tainers is automatically containerized, yearly vehicle fleet requirements 
and vehicle end-of-life are computed, the shipment of additional/replacement 
vehicles is provided for, propellant requirements for the mission legs are 
computed, and the shipment of propellant is provided for. These computed 
cargo items are then added to the initial cargo items for the outermost leg 
to form a cargo list to be transported on the leg preceding the outermost leg. 
This process is repeated until all legs of the mission profile have been 
accommodated. As the process is repeated, the cargo manifests for pre- 
ceding legs increase considerably in size. 

If, in addition to the factor mentioned above, other missions create the 
requirement for cargo to be shipped on the same legs, the cargo manifests 
may increase even further as shown in Fig. 2. The accommodation of all 
cargo on a given leg regardless of the mission generating the requirements 
is designated "mission interaction" and is an integral part of the cargo load- 
ing procedure. This interaction feature permits looking at the total space 
program effects in an integrated sense, rather than looking at each mission 
independently and adding the independent results to obtain total program 
effects. While the unrestricted use of mission interaction effects may not 
be completely accurate, it is if suitably moderated, more realistic than the 
independent mission approach which tends to be overly conservative. The 
program contains several loading options that can be used to simulate 
"real-world" situations. 
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CARGO LOADING 


5. 2 

Cargo items are loaded aboard vehicles in descending order of weight until 
vehicle structural and/or volumetric limitations prohibit further loading. 

Since cargo items for both deployment (up) and retrieval (down) must be 
considered, both are included in the cargo listings. To simplify the loading 
procedure, all down cargo items are assigned an "equivalent up weight" and 
thereafter treated as up cargo, see Fig. 3. In this way, the cargo can be 
loaded in a systematic manner disregarding direction of flight; however 
volumetric checks must be performed independently for both directions. 

The "equivalent up weight" of a cargo item equals the product of cargo actual 
weight and the ratio of the vehicle deployment (up) capability to retrieval 
(down) capability. 

This equivalency takes cognizance of the fact that it requires substantially 
more energy to retrieve a payload than to deploy one on an orbit-to-orbit 
leg, and that it requires virtually zero energy to return a payload to earth 
from earth orbit. 

This method of loading while not an optimization procedure, does tend to 
maximize the vehicle load factor, which is the primary intent of the proce- 
dure. Load factors can be further improved by topping-off the vehicle with 
general purpose support cargo, termed bulk cargo, ‘if such cargo is scheduled 
to be delivered in the same time period. Bulk cargo is presumed to have no 
geometric configuration and can, more or less, be loaded into a general 
purpose logistics container much like grain into a freight car. 

There are constraints of vehicle structural and geometric limitations using 
the above provedure; further constraints are optional loading restrictions 
that may be applied by the user, see Fig. 4. 
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Loading Cargo Aboard Vehicles 




Fig. 4. Optional and Standard Cargo Loading Restrictions 





One of these options is the single deployment option which limits vehicle 
load to a single cargo item. This option may be applied to specific cargo 
items, vehicles, or mission legs; however, in general, primary application 
of the option will be to the cargo item. 

Another option is the coupling option which specifies that certain cargo com- 
binations or cargo- vehicle combinations are to be transported together on a 
given leg or aboard a given vehicle. One of the major applications of this 
option is in the simulation of ground-based operations. Subject to the specific 
ground-based definition being used, orbital capabilities with respect to assem- 
bly and docking operations may vary considerably. Regardless of the vehicle- 
payload combinations on the upper leg, simulation of ground-based operations 
necessitates placing restrictions on the cargo and/or car go- vehicle com- 
binations that may be shipped to earth orbit from the ground. In this case, 
when restrictions are placed on cargo/vehicle configurations, the couple 
operation is automatically performed according to any restrictions specified 
within the program. 

For example, if a tug is capable of delivering four payloads from low earth 
orbit to some higher orbit, it may or may not be usable to transport all four 
payloads depending on the orbital "assembly" restrictions imposed by the 
definition of ground-based operations by the user. 

If the user permits vehicle-to- payload docking in orbit and, if an assembly 
of three of the four payloads and the tug will individually fit in the EOS (but 
will not if docked together), programming would place the three payloads 
to orbit on one EOS flight and the tug on another. In orbit, the two elements 
would dock and the three payloads would be transported by tug to final 
destinations. The fourth payload would be scheduled for another tug flight. 

If, however, the user permits only vehicle- to- vehicle docking, the tug and 
payloads must be docked together prior to shipment to earth orbit. This 
means that the tug and the payloads to be delivered by the tug to a higher 
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orbit must be shipped together on the same EOS flight. Obviously, at least 
one of the three previously acceptable payloads must be discarded and resched- 
uled for another tug flight. In this case, two payloads, at most, would be 
delivered by tug to the higher orbit. 

If the user wanted to consider a more universal docking capability, the tug 
and the four payloads would be shipped to earth orbit independently (but not 
necessarily on different EOS flights). Once on orbit, the payloads and the 
tug would be docked and the four payloads transported to final destination 
by the tug. 

For any given leg, the vehicles utilized in the cargo loading exercise may be 
specified by the analyst, or the selection may be programmed by exercising 
the "capture" option. When this option is selected, an ordered list of vehicles 
become available for service on the leg. The time span for which the vehicles 
are available to service the leg is also specified. The first cargo in the cargo 
table is used to determine the vehicle to be used for the flight. From the 
ordered sequence of vehicles, selection is made from the first vehicle that 
has sufficient performance to transport the cargo to its destination, see Fig. 5. 
The loading routine continues and the vehicle is loaded in this manner subject, 
of course, to the optional restrictions previously discussed. After the vehicle 
has been loaded, the procedure is repeated successively until all cargo in the 
leg cargo manifest has been exhausted. 

Similarly, vehicle performance capabilities may be specified by the user, or 
the computation may be left to the program depending on the type of data the 
user processes for input to the program. If performance is known, it is 
entered in the form of up, down, and expended capabilities on each of the legs 
the vehicle services. If performance is unknown, the vehicle capabilities 
will be computed (by successive loading iterations) when the mission (leg) 

AVs, vehicle engine Isp, and characteristic weights associated with the vehicle 
configuration are provided as input. In the event both sets of data are present 
in the input, known performance figures will be assumed to be correct and be 
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used in the cargo loading process. When computations are required, they 
are executed and results appropriately stored prior to having the cargo 
loading procedure initiated. 

5. . PROPELLANT COMPUTATION 

Once a vehicle has been fully loaded, flight of the vehicle is scheduled and 

propellant required for the vehicle is computed in the DORCA program. The 

propellant requirement is normally based on flight of the vehicle with a full 

load of propellant, since the majority of vehicles determined for flight by the 

cargo loading feature are flown with high load factors. In this case, propellant 

requirement is computed as being the product of the number of vehicle flights 

and the propellant capacity of each vehicle. In cases where the space 

program structure creates a significant number of flights with low load 

factors, the user has the option of requiring DORCA computations for the 

propellant required, based on the payload weight being transported. In general, 

% 

the user would want to take this option since any reduction of the propellant to 
be delivered will have a significant impact on predecessor leg traffic rates. In 
either case, the propellant, contained in appropriate tankage, is automatically 
added to the cargo list for the leg preceeding the one that the vehicle is 
servicing. 

The option whereby the vehicle propellant computation is based on payload 
weight is referred to as the propellant off-loading option since this option, in 
effect, requires off-load of propellant from the vehicle. With the option, the 
same computational routine is utilized that is used to compute orbit- to-orbit 
performance capability, and will accommodate either single of multistaged 
vehicles. In the case of multistaged vehicles, the routine was formulated to 
simulate a slingshot performance mode whereby maximum burns are executed 
by each stage in succession as the vehicle progresses along the mission 
trajectory. In the actual computation, the routine proceeds in reverse order, 
computing first the increment of total mission AV that the upper stage can 
accommodate with the payload and full load of propellant. The procedure is 
repeated for other stages in sequence, see Fig. 6. The remaining mission 
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NOTE: WHEN REMAINING MISSION CAPABILITY OF THE 

STAGE, THAT STAGE CONSTITUTES THE FINAL STAGE 
OF THE MULTI-STAGE VEHICLE AND CAN BE 
CONSIDERED FOR PROPELLANT OFF-LOADING 


Fig. 6. Vehicle Performance /Propellant Computation Methodology 
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AV to be accommodated by the lower (first-to-burn) stage is thereby 
determined and a computation solving for the propellant required is made. 

The first stage is then loaded with the computed quantity of propellant and the 
mission flown with the first stage off-loaded. It is typical of the routine that 
the lower stage of a multistage vehicle is the stage that is propellant off-loaded 
since, from a total vehicle performance point of view, it is nearly always more 
efficient to off-load the lower stage of the vehicle and have the dead weight of 
the stage jettisoned as soon as possible. 

5.4 VEHICLE TRAFFIC /FLEET COMPUTATION 

With the cargo loading routine, the task of loading the vehicles in compliance 
with the optional restrictions invoked by the user is performed. The assign- 
ment of cargo items to individual vehicles, the determination of the number 
of vehicles required to accommodate yearly flight rates, and the maintenance 
of bookkeeping required to track the number of flights accumulated on indi- 
vidual vehicles are performed by companion routines of the loading algorithm. 
These routines are required in order that yearly and total vehicle fleet require- 
ments may be determined when appropriate vehicle service limitations are 
specified. The yearly number of flights in which each vehicle is used and the 
total number of flights and/or number of years constituting a vehicle lifetime 
have a sizable impact on vehicle flight requirements and therefore cost of 
the space program. These service limitations are specified in the DORCA 
input and can be changed on successive runs if it is deemed desirable to 
investigate the effects of varying service limitations of the vehicle. 

The yearly total number of flights is distributed as equally as possible using 
all available vehicles in compliance with the following limitations: (1) maximum 
yearly flight rate is not exceeded; (2) maximum total number of flights 
(lifetime) is not exceeded; (3) maximum total years of service (lifetime) is 
not exceeded; and, (4) vehicle has not fallen below its average cumulative 
flight value [(max total flights/max total years) times years service]. The 
latter restriction is to force vehicle retirement via the total flight limitation 
rather than by the years in service if at all possible. 
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Vehicle acquisitions are made on the basis of the number of vehicles 
required to accommodate the number of flights scheduled for the year. If 
the total number of flights available from the existing vehicle inventory 
(based on the first three limitations above) is less than the number of (lights 
scheduled, sufficient additional vehicles are obtained to assure that all flights 
can be accommodated (Fig. 7). 

5. 5 COST COMPUTATION 

Once vehicle loading and scheduling have been accomplished and traffic rates 
and fleet acquisition determined, the program costs are determined. The 
cost and cost distribution factors utilized are part of the basic data input and 
for the most part are just arithmetically summarized in the program (Fig. 8). 
The cost report contains cost subtotals for: (1) vehicle costs; (2) payload 

costs; and (3) operations costs. 

The RDT&E and procurement cost of all vehicles, by name and fiscal year are 
included in vehicle cost subtotal. These costs are not correlated to, nor dis- 
tributed among the missions in which the vehicles are utilized. 

The payload cost subtotal contains the same information for payloads that the 
vehicle cost subtotal does for vehicles. However, these costs are additionally 
correlated to and distributed among the missions /programs utilizing them. 

The operations cost, which is the sum of the direct cost of operating the 
vehicles on a per flight basis, is correlated to and distributed among the 
cargo items. The cost of each flight is apportioned to the individual cargo 
items aboard the flight in the following manner. 


OPERATIONS COST = FLIGHT COST 
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Cost Computation and Summarization 



In general the cargo items can be correlated to a specific mission/program, 
therefore, the operations costs can for the most part be allocated to the 
missions themselves. Some categories of cargo (e.g. , vehicles and containers) 
cannot be easily correlated to specific missions, and therefore costs are 
in a determined special overhead account within the operations cost subtotal. 
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6. DORCA APPLICATIONS 


The DORCA program can be a very useful tool in the decision making process 
at the programmatic level where decisions are dependent on parameters 
involving vehicle flight rates, vehicle inventories, operations costs, or total 
program cost. The pilot version of DORCA was utilized to conduct a space 
tug sizing analysis and to assess programmatic effects of ground-based versus 
space-based vehicle operations. Results, while reported at the regular study 
review meetings, were not widely circulated because of the number of approxi- 
mations involved using the pilot program. While it was necessary with the 
pilot program, to make approximations, much of this is eliminated with the 
present DORCA program. 

DORCA is presently being utilized to conduct mechanized payload capture 
analyses for comparison with the manual capture analysis performed in 
conjunction with another NASA funded Aerospace Corporation study. Results 
of the mechanized capture analyses agree with the values obtained manually, 
within two percent. Capture analyses have been performed manually to 
the present time; serious consideration is being given to conducting future 
capture analyses in the mechanized mode because of the considerable time 
savings involved. 
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